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SYSTEM AND METHOD FOR IMPLEMENTING A SCHEMA OBJECT 

MODEL IN APPLICATION INTEGRATION 
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METHOD FOR IMPLEMENTING AN EVENT ADAPTER," by Mitch Upton, 
filed October 15, 2002. 

U.S. Patent Application No. entitled "SYSTEM AND 
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METHOD UTILIZING AN INTERFACE COMPONENT TO QUERY A 
DOCUMENT," by Mitch Upton, filed October 15, 2002. 

U.S. Patent Application No. entitled "SYSTEM AND 

10 METHOD USING ASYNCHRONOUS MESSAGING FOR APPLICATION 

INTEGRATION," by Mitch Upton, filed October 1 5, 2002. 

U.S. Patent Application No. ' entitled "SYSTEM AND 
METHOD FOR IMPLEMENTING A SERVICE ADAPTER," by Mitch Upton, 
15 filed October 15, 2002. 

COPYRIGHT NOTICE 
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patent file or records, but otherwise reserves all copyright rights 
whatsoever. 
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U.S. Patent Application No. entitled "APPLICATION VIEW 

COMPONENT FOR SYSTEM INTEGRATION." by Mitch Upton, filed 
October 1 5, 2002. 

5 U.S. Patent Application No. entitled "SYSTEM AND 

METHOD FOR PROVIDING A JAVA INTERFACE TO AN APPLICATION 
VIEW COMPONENT," by Mitch Upton, filed October 1 5. 2002. 

U.S. Patent Application No. entitled "SYSTEM AND 

10 METHOD FOR INVOKING BUSINESS FUNCTIONALITY FOR A 

WORKFLOW," by Mitch Upton, filed October 15, 2002. 

U.S. Patent Application No. entitled "SYSTEM AND 

METHOD FOR USING WEB SERVICES WITH AN ENTERPRISE 
15 SYSTEM," by Mitch Upton, filed October 1 5, 2002. 

U.S. Patent Application No: entitled "SYSTEM AND 

METHOD FOR IMPLEMENTING AN EVENT ADAPTER." by Mitch Upton, 
filed October 15, 2002. 

20 

U.S. Patent Application No. entitled "SYSTEM AND 

METHOD USING A CONNECTOR ARCHITECTURE FOR APPLICATION 
INTEGRATION," by Mitch Upton, filed October 15, 2002. 

25 U.S. Patent Application No. __ entitled "SYSTEM AND 

METHOD UTILIZING AN INTERFACE COMPONENT TO QUERY A 
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U.S. Patent Application No. entitled "SYSTEM AND 

METHOD USING ASYNCHRONOUS MESSAGING FOR APPLICATION 
INTEGRATION," by Mitch Upton, filed October 15, 2002. 

5 U.S. Patent Application No. entitled "SYSTEMS AND 

METHODS FOR INTEGRATION ADAPTER SECURITY." by Mitch Upton, 
filed October 1 5. 2002. 

U.S. Patent Application No. entitled "SYSTEM AND 

10 METHOD FOR IMPLEMENTING A SERVICE ADAPTER," by Mitch Upton, 

filed October 15, 2002. 

FIELD OF THE INVENTION 
The invention relates generally to systems and methods for 

p 

15 integrating applications. 

BACKGROUND OF THE INVENTION 
E-commerce has become a major driving factor in the new 
economy. To be successful in the long-term, e-commerce will require 

20 many companies to engage in cross-enterprise collaborations. To achieve 

cross-enterprise integration , a company must first integrate its internal 
applications. Using existing technology and tools, application integration 
can be an expensive proposition. No integration solution exists that is easy 
to use, affordable, and based on industry standards. Neither does a 

25 solution exist that is based on an industry standard infrastructure, has 

universal connectivity, is capable of massive scalability, and has accessible 
business process tools. 
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Application integration to this point has been very inward-focused. 
Many existing integration systems have not focused on integrating 
applications between enterprises. Even when integration solutions were 
used for cross-enterprise integration, the solutions were still narrowly 
focused and aimed at vertical markets. This inward focus did little to help 
companies field external business-to-consumer and business-to-business 
applications, such as applications that can utilize the Internet to generate 
revenue and reduce costs. The requirement for Internet-enabled 
applications led to the rise of the application server market. To date, 
application servers have primarily been used to host external applications 
targeted at customers and partners. Application servers are themselves 
packaged applications that, instead of solving a specific problem, are 
general-purpose platforms that host vertical solutions. 

The first attempts at application integration were primarily focused 
on low-level implementation details such as the format of the data, the byte 
ordering between machines, and character encoding. The focus on low- 
level data formats was necessary because, for the first generation of 
application integration solutions, there were no widely adopted standards 
for data encoding that could be deployed across multiple vertical 
applications. 

The traditional approach involved connecting individual systems to, 
in effect, hardwire the systems together. This approach can be complex, 
as connecting different systems can require an intimate, low-level 
knowledge of the proprietary technologies of multiple systems. 

Present integration systems, which have moved away from 
"hardwiring" systems together, still suffer from a lack of standards. Each 
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integration vendor typically provides a proprietary solution for application 
integration, message transformation, message formats, message transport, 
and routing. Not one of these systems to date has achieved significant 
market share to enable its technologies to become the de-facto standard. 
This lack of standards has given packaged application vendors little 
incentive to integrate these systems with their. Further, each of these 
integration systems or servers has its own proprietary API, such that 
packaged application vendors cannot leverage development beyond a 
single integration server. This fragmentation of the integration market has 
provided little financial incentive for third parties. 

* 

SUMMARY OF THE INVENTION 
Systems and methods in accordance with embodiments of the 
present invention allow communication to be passed between components, 
such as an enterprise system and a client application, by taking advantage 
of schemas. A schema can be used to ensure that a communication, such 
as a request or response, is in the proper format for one of the 
components. For instance, metadata can be received from an enterprise 
system in response to a request from a client application. That metadata 
can be transformed to a response document that conforms to a schema. 
The document can be validated against the schema and passed on to the 
client application. 

w 

Other features, aspects, and objects of the invention can be 
obtained from a review of the specification, the figures, and the claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 
Figure 1 is a diagram of an integration system that can be used in 
accordance with one embodiment of the present invention. 
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Figure 2 is a diagram of an integration system that can be used in 
accordance with another embodiment of the present invention. 

Figure 3 shows a method that can be used with the systems of 
5 Figures 1 and 2. 

Figure 4 is a flowchart showing a process that can be used with the 
systems of Figures 1 and 2. 

10 DETAILED DESCRIPTION OF THE INVENTION 

Application integration components can be used to integrate a 
variety of applications and systems, such as Enterprise Information 
Systems (EISs). Information technology (IT) organizations typically utilize 
several highly-specialized applications. Without a common integration 
1 5 platform to facilitate application-level integration, these applications cannot 

be integrated without extensive, highly-specialized development efforts. 

Application integration can utilize adapters to establish an 
enterprise-wide, united framework for integrating any current or future 
20 application. Adapters can simplify integration efforts by allowing each 

application to be integrated with an application server, instead of requiring 
that each application being integrated with every other application. 

The development and widespread acceptance of standards such as 
25 the Java 2 Platform, Enterprise Edition (J2EE)from Sun Microsystems, Inc. 

of Santa Clara, CA, as well as the extensible Markup Language (XML), 
' has laid the groundwork for a standardized approach to the development 
of these adapters. Perhaps the most significant of these standards for 
application integration is the J2EE Connector architecture. The J2EE 
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Connector architecture provides a standardized approach for the 
development of adapters for all types of applications, from legacy 
mainframe applications, such as CICS from IBM, to packaged applications 
such as PeopleSoft, Siebel, and SAP. The adoption of such standards 
enables businesses to develop adapters that work on any J2EE-compliant 
application server, for example. 

Integration Architecture 

Application integration can build on this standardized approach in 
an application integration framework by providing a standards-based 
architecture for hosting J2EE Connector architecture-based adapters. 
Developers can build J2EE Connector architecture-compliant adapters and 
deploy these adapters, in the integration framework, to connect enterprise 
applications to an application server. 

These adapters can be used to define business-focused interfaces 
to an EIS, the interfaces referred to herein as "application views" of the 
respective adapters. An application view can provide a simple, self- 
describing, consistent interface to services and events in an application. 
Application views can make use of an adapter for an EIS, making it 
possible to expose existing information systems as business services. 
Unlike adapters, however, an application view does not require users to 
have intimate knowledge of the EIS or the client interface for that EIS, such 
that non-programmers or technical analysts can use application views. An 
application view can provide a business-oriented way for business analysts 
to access enterprise data without worrying about the programmatic details 
defined in an adapter. These same users may be otherwise unable to use 
an adapter directly, due to a lack of familiarity with the EIS, 
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An application integration component directed at enterprise 
' application integration can have several primary aspects. If the 
functionality of an EIS such as a PeopleSoft system or an SAP system is 
to be invoked, an implementation of the J2EE Connector Architecture can 
5 be used. If something occurs inside an EIS system, such as a trigger going 

off, an event can be generated. This event may, in some embodiments, 
need to be communicated to an external application. An event architecture 
in an application integration component can handle this communication. 

10 A pplication Views 

An application view can provide significant value to an application 
integration component An application view can abstract away much of the 
complexity in dealing with an application, such as a backend EIS system. 
Application views can also simplify the way in which adapters are 

15 accessed. Application views can provide a layer of abstraction, for 

example, between an adapter and the EIS functions exposed by that 
adapter. Instead of accessing an EIS by direct programming a user can 
simply: edit an adapter's application views, create new application views, 
or delete any obsolete application view(s). A layer of abstraction formed by 

20 application views can help non-programmers maintain the services and 

events exposed by an adapter. Each application view can be specific to a 
single adapter, and can define a set of business functions on that adapter's 
EIS. After an adapter is created, a Web-based interface for the adapter 
can be used to define application views. 

25 

If an application view is used as a primary user interface for an 
adapter, a number of features can be included that are not commonly 
. found in existing enterprise application integration technologies. Application 
views can, for example, use XML as a common language among 

* 
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applications. Service and event definitions can be used to expose 
application capabilities. XML schemas can be used to define the data for 
services and events. Bidirectional communication can also be supported 
in adapters. 

♦ 

An application view can be an integral part of an integration 
framework. An application view can provide a view of the application 
capabilities exposed by an adapter that a user can customize to meet 
specific needs. A user can tailor an application view, for example, for a 
specific business purpose. As a result, the application view can provide an 
effective alternative to the "one size fits air approach that many 
applications provide for the design of a client interface. An application view 
can be defined for only the business or other capabilities that are 
applicable for a specific purpose. The capabilities can be customized such 
as by naming, describing, and defining the data requirements. 

In one example, shown in Figure 1 , adapters 106, 108, 110 can be 
developed that allow a client application 100 to communicate with an 
Enterprise Information System 104 through the use of an application view 
20 102. A developer can begin by coding an adapter that exposes the 

functionality in the enterprise application that accesses enterprise data. 
The functionality the adapter exposes could, for example, update records 
in a database using SQL statements, or could request information from an 
SAP system using its BAPI or IDOC interfaces. A business analyst, 
25 working with the developer, can then define an application view of the 

adapter using an application view interface. 

Another example of a system is shown in Figure 2. In this figure, 
a client application 200 can communicate with an EIS 218 through an 

-10- 
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integration server 202. The integration server can be, for example, a web 
server or application server 202, and can be included in a cluster or 
integration system, represented here by the dotted line. The integration 
server can include an application view component 204 and a resource 
5 adapter 206 for the EIS 218. An XML schema API 208, useful in 

generating an XML schema 214 for the client application 200 using the 
schema object model 212 can be included in the integration server 202. 
An XML document API 210, which can provide an interface to an XML 

■ 

document using an IDocument component 216 such as IDoc class 
10 libraries, for example, can also be. included on the integration server 202. 

The schema object model 212, XML schema 214, and IDocument 
component 21 6 do not need to be contained on the integration server 202, 
but should be accessible to the integration server. 

15 An application view is an object, which can be implemented in one 

embodiment as a stateless session JavaBean. There can be a Java 
interface to the application view for the client application. A Java 
application can be custom coded to use that object, such as by passing 
XML in and receiving XML back. In addition, a business process manager 

20 component can be included that allows process engineers to define 

workflows, and allows application views to be invoked as business 
services. In a workflow, a callout can be made to an EIS to get information 
such as a customer's credit record. The fact that the application view is a 
Java object or enterprise JavaBean can be hidden from the process and 

25 designer. 

A web services interface can also be used with an application view. 
A protocol such as SOAP can be used to invoke a web service. Another 
protocol that may be used includes UDDI, a platform-independent, open 

* 
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framework for describing services, discovering businesses, and integrating 
business services using the Internet. A WSDL protocol can also be used, 
which is an XML format for describing network services . A web services 
layer can be provided on top of the application view so that any application 
view can be invoked as a web service. 

In application integration, new application views can be hot- 
deployed against an existing EIS through a web-based interface. An 
application view is hot-deployed when it is deployed with the system 
running, without restarting the destination server. A new customer 
management tool for SAP, for example, can also be defined through a web 
browser. 

Integration Framework 

Application integration can utilize an integration framework, which 
can provide a systematic, standards-based architecture for hosting 
application views. Features of such a framework can include application 
views for exposing application functions and design-time graphical user 
interfaces (GUIs), such as web-based interfaces that can be used for 
creating application views. The integration framework utilizes adapters, 
instead of "hardwiring" enterprise systems together. Once an adapter is 
deployed for an EIS, other components and applications can use that 
adapter to access data on the EIS. 

A framework in accordance with one embodiment of the present 
invention relies on XML as the standard format for messages. XML 
includes XSLT, a standard for transforming XML documents into other XML 
documents. XSLT is designed for use as part of XSL, which is a stylesheet 
language for XML. In XSLT, an XML document Is used to specify the 
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operations to perform on a class of XML documents in order to transform 
the documents 1 structure and content. An XSLT transformation can make 
use of any of the operations built into the Java programming language, or 
can make use of custom operations written either in Java or in native code. 
An integration framework allows a business process to invoke an XSLT 
engine in order to transform XML messages. 

An integration framework can also rely on standards for transporting 
messages such as Java Message Service (JMS) and HTTPS. JMS is a 
standard API for interfacing with message transport systems. Using JMS, 
a framework can utilize any message transport mechanism that provides 
a JMS interface. The J2EE Connector architecture standard does not 
specify a message transport mechanism, but an application integration 
framework can specify such a transport mechanism. 

An integration framework can be based on an existing standard 
infrastructure, such as an application server that supports J2EE, JMS, and 
the J2EE Connector architecture. Using such a standard infrastructure 
also provides for high availability and scalability, such as by clustering and 
resource pooling. The framework can provide for universal connectivity by 
enabling the construction of XML-based application adapters that can 
connect to any legacy and packaged application. An adapter development 
kit can be used to allow users such as customers, system integrators, and 
packaged application vendors to quickly develop J2EE connector 
architecture-compliant and integration framework-based adapters. The 
framework can utilize XML, which means that the same data format can be 
used for both within- and between-enterprise integration, since many e- 
. commerce systems use XML as the standard message format. 
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An integration framework can also utilize a business-process engine 
to allow non-programmers to graphically construct and maintain business 
processes. An integration framework can implement a common model on 
top of the J2EE Connector architecture that is focused on business-level 
concepts. This model, which can consist of XML-encoded events and 
services, allows the management of a consistent integration environment, 
regardless of the interface required between adapters and their target 
applications. The business processes can react to events generated by 
applications, and they can invoke an application's functionality via sen/ices 
that are exposed by an application adapter. 

Adapter Development 

XML development tools, such as may be included in an ADK, can 
be considered part of a metadata support layer for a design-time 
framework. These tools, which can comprise an XML Toolkit, can include 
an XML schema API, which can be characterized by a Schema Object 
Model (SOM). This API can be used to programmatically build XML 
schemas. An adapter can call an enterprise system or EIS for specific 
request and response metadata, which can then be programmatically 
transformed into an XML schema. The SOM is a set of tools that can 
extract many of the common details, such as syntactical complexities of 
XML schema operations so that a user can focus on its more fundamental 
aspects. Another tool that can be included is an XML Document API, 
which can be characterized by IDocument. This API can provide an x-path 
interface to a document object model (DOM) document. 

An IDocument, which can facilitate XML input and output from the 
CCI layer in an adapter, is a higher-order wrapper around the W3C 
Document Object Model (DOM). The primary value-add of the IDocument 
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interface is that it provides an XPath interface to elements in an XML 
document. In other words, IDocumentobjectsarequeryableand updatable 
using XPath strings. For example, the following XML document describes 
a person named "Bob" and some of the details about "Bob." 

5 <Peraon name="Bob M > 

<Home square Fee t=" 20 00 M /> 
< Family > 

<Child name o "Jimmy "> 

<Stats genders "male" haire "brown" eyee="blue"/> 
10 </Child> 

<Child name= " Susie" > 

<Stats gender=" female" hair= "blonde" eyes=" brown "/> 
</Child> 
</ Family > 
15 </Pereon> 

By using I Document, Jimmy's hair color can be retrieved using code 
such as: 

System.out.printlnfJimmy's hair color " ♦ 
20 person.getStringFrorntV/Personlgname^BobH/Famlly/Child 

[@name=rjlmmy\n/Stats/@hair); 

On the other hand, if DOM is used it would be necessary to use 
code such as: 

25 String strJImmysHairColor = null; 

org.w3c.dom.Element root = doc.getDocumentElement(); 
If (root.getTagName().equalsf Person") && 
root.getAttribute( B nam8").equalsfBob"){ 
org.w3c.dom.NodeList list = root. 
30 getElementsByTagNamefFamily"); 

If (Hst.getLength() > 0) { 
org.w3c.dom.Element family = (org.w3c.dom. 
Element)Jlst.ltem(O); 

35 org.w3c.dom.NodeList childLlst = famiiy.getDementsByTagName("ChHd M ); 

for (int l=0; i < child List.getLength(); i*+) { 
org.w3c.dom.Element child = childlist.item(i); 

if (child.getAttributername^.equalsCJimmy")) { 
org.w3c.dom.NodeList statsList = 
40 child.getElement$ByTagName("Stats w ); 

if (statsList.getLength(j > 0) { 
org.w3c.dom.Element stats = statsList .item(0); 
StrJImmysHairColor = stats^etAttributeChair"); 

} 

45 } 
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} 

} 

} 

XCCI Design Pattern 

A common design pattern that emerges when using an XCCI 
approach is to support the definition of services in an interaction 
implementation. In other words, a javax.resource.cci.lnteraction 
implementation for an adapter can allow a client program to retrieve 
metadata from an underlying EIS in order to define an Integration service. 
Specifically, this means that the interaction must be able to generate the 
request and response XML schemas and additional metadata for a service. 
Additionally, the Interaction could also allow a client program to browse a 
catalog of functions provided by the EIS. This approach facilitates a thin 
client architecture for an adapter. 

Data Transformation Method 

Data transformation is the process of taking data from an enterprise 
system and transforming the data into an XML schema that can be read by 
the application server. For each event, a schema can define what the XML 
output looks like. This can accomplished by using SOM and IDocument 
class libraries. 

The following sample code listings show one data transformation 
sequence. The following code can be used to transform data from an EIS 
into an XML schema: 

SOMSchema schema = new SOMSchemaQ; 
SOMElement root = new SOMEIement("SENDINPUT"); 
SOMComplexType mailType = new SOMComplexType(); 
root.setType(mallType); 

SOMSequence sequence = mailType.addSequence(); 
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SOMEIement to = new SOMEIernentfTCT); 
to.setMinOccursfT); 
to.setMaxOccurs("unbounded"); 
sequence.add(to); 

SOMEIement from = new SOMEIement("FROM H ); 
from.setMlnOccursfr); 
from.setMaxOccursf T); 
sequence, add(from); 
, SOMEIement cc = new SOMEIement( n CC"); 
cc.setMlnOccurs("1 M ); 
cc.setMaxOccursCunbounded'); 
sequence .add(cc); 

SOMEIement bcc = new SOMEIementfBCC"); 
bcc.setMinOccurs("1 "); 
bcc.setMaxOccursfunbounded"); 
sequence, add(bcc); 

SOMEIement subject « new SOMElementfSUBJECr); 

subjectsetMinOccursfr); 

subjecUetMaxOccursfr); 

sequence.add(bcc); 

SOMEIement body = new SOMEIement( B BODY w ); 
if (template == null) 

{ body.setMinOccursP"}; 
body setMaxOccursfr ); 

Jetse 

{ Iterator iter = template.getTags(); 
if (iter.hasNextO) 

{ SOMComplexType bodyComplex = new SOMComplexType(); 
body.setType(bodyComplex); 
SOMAII all = new SOMAII(); 
while (iter.hasNext()) 

{ SOMEIement eNew = new SOMEIement((String)iter.next()); 

all.add(eNew); 
}//endwhile 

bodyComplex.setGroup(all); 
}//endif 
}//endif 
sequence.add(body); 
schema.addElement(root); 



The following example shows an XML schema created bythe above 

« 

code: 

<xsd:schema xmlns:xsd= tt http://www.w3.org/2001/XMLSchema H > 
<xsd:element name="SENDINPUr> 
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<xsd:complexType> 
<xsd:sequence> 
<xsd:etement name=TO M maxOccurs="unbounded" 

type=5"x8d: string7> 
<xsd:element name= H FROM" type= M xsd:string , V> 
<xsd:element name="CC" maxOccurs=Ajn bounded" 

type="xsd:string7> 
<xsd:element name="BCC" maxOccurs= 

"unbounded" type= w xsd:string7> 
<xsd:element name="BCC" maxOccurs="unbounded M 

type= M xsd:string7> 

> 

<xsd:element name="BODY" type="xsd:string7> 
</xsd:8equence> 
</xsd:complexType> 
</xsd:element> 

The following example shows a valid XML document created by the 
schema shown above: 

</xsd:schema> 
<?xml version=M.0"?> 
<!DOCTYPE SENDINPUT> 
<SENDINPUT> 

<TO/> 

<FROM/> 

<CC/> 

<BCC/> 

<BCC/> 

<BODY/> 

</SENDINPUT> <xsd:schema xmlns:xsd = 
"http;//www.w3.org/2001/XMLSchema M > 
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The adapter can be tested and then deployed. An adapter can be 
deployed manually, or through a tool such as a server or integration 
console. 

XML Toolkit 

An XML toolkit can be utilized that can help to develop valid XML 
documents to transmit information from a resource or enterprise system to 
an application on the other side of an adapter. The toolkit can incorporate 
many of the operations required for XML manipulation into a single 
location, relieving the user of these often tedious chores. 

An XML toolkit can be comprised primarily of two Java packages, 
such as a com.document package and a com.schema package. These 
packages can include complete Javadocs for each class, interface, and 
method. 

IDOC 

An IDocument, or IDoc, is a container that combines the W3C 
Document Object Model (DOM) with an XPath interface to elements in an 
XML document. This combination can make IDocument objects queryable 
and updatable simply by using XPath strings. These strings can eliminate 
the need to parse through an entire XML document to find specific 
information by allowing a user to specify just the elements the user wants 
to query and then returning the values of those queries. 

An IDocument can be a public interface that represents an XML 
document. An IDocument can provide a document type name, which can 
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be used to refer to a description of its structure and usage. In addition, 
IDocuments can be mutable, and can provide methods for retrieving, 
modifying, adding, and removing data elements. All IDocument objects can 
be queryable, and can be updatable such as by using XPath strings. Also, 
IDocument instances can be serializable to, and un-serializable from, XML. 
IDocument objects can implement a Java interface such as 
javaJo.Serializable. 

The default representation of the document represented by an 
IDocument can be a W3C DOM instance, such as org.w3c.dom. Document. 
The IDocument may at times be in an unparsed state. This can happen if 
the IDocument was explicitly constructed this way, by using a method such 
as DocumentFactory.createDocument(String, boolean), for example, where 
the boolean argument is 'true/ The internal state of an IDocument can be 
determined using a method such as isParsed(). If this returns true, then the 
content of the document has been parsed into a DOM. If 'false* is 
returned, the IDocument may contain just the raw XML text. 

In cases where an IDocument is in an unparsed state, the content 
can be parsed using a SAX parsing scheme that allows a user to build an 
in-memory representation of the document that is not DOM. A method such 
asfromXML(ContentHandler)can be used for this purpose, allowing a user 
to parse the document's content manually using an interface such as an 
implementation of a ContentHandler interface. A user could achieve similar 
results by getting the raw content from the IDocument and 
creating/invoking a custom SAX parser. 
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I Document can simplify the code necessary to query and find 
information in a document, as opposed to code such as DOM code. For 
example, the following XML document describes a person named "Bob" 
and some of the details about "Bob": 

< Person name="Bob'»> 

<Home squareFeeta"200O w /> 
<Family> 

<Child names "Jimmy" > 

<State sex="male" hair= "brown" eyes="blue°/> 
</Child> 

<Child names "Susie "> 

<Stats eex= tt female" hair= "blonde" eyes=" brown" /> 
</Child> 
</Family> 
</Person> 

In order to retrieve Jimmy's hair color from the <child> element by 
using IDocument, an XPath string can be created that seeks exactly that 
information, as shown the following IDocument data retrieval code sample: 

System.out.println(\Jlmmy's hair color: " + person.getStringFrom 
n/Person[@namB=\ M Bob\T/Family/Child[@name=rjlmmy\7Sta 

Schema Object Model fSOM) 

A schema object model (SOM) is an interface useful for 
programmatically building schemas, such as XML schemas. SOM can 
comprise a set of tools that can extract and validate many of the common 
details, such as syntactical complexities of schema, so that a user can 
focus on more fundamental aspects. As shown in the method of Figure 3, 
for example, an XML schema can be created for a client application using 
a schema object model 300. A component such as a resource adapter can 
call into an EIS for specific request/response metadata. Metadata can be 
received from the EIS in response to the request 302, which can be 
programmatically transformed into an XML document that conforms to the 
XML schema for the client application 304. At least a portion of the XML 
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document can be validated against the XML schema for the client 
application 306. An IDocument interface can be used to parse and/or 
retrieve elements or portions from the XML document in order to validate 
those elements or portions. Once the XML document is validated, it can 
be passed to the client application as a response document 308. 

A flowchart for such a method is shown in Figure 4. The request is 
received from the client application to an EIS 400. The EIS returns 
metadata in response to the request 402. The metadata is transformed 
into an XML document 404. At least portions of the XML document can be 
parsed or extracted, such as by using an IDocument interface, and can be 
compared to the XML schema for the client application in order to validate 
those portions 406. A determination is made as to whether each portion 
is valid 408. If each portion is valid, the validated XML document can be 
returned to the client as a response document 410. If each portion is not 
valid, a determination should be made whether the client application should 
receive invalid documents 412. If the client should receive an invalid 
document, each error can be logged 414 and the validated (or invalidated) 
XML document is passed to the client as a response document 410. 

If the client should not receive an invalid XML document, a 
determination should be made whether an end condition has been met 
416. An end condition can be set so that an infinite loop is not created if 
the metadata cannot be transformed into a valid XML document. "Valid" 
in this instance means that the XML document is valid against the XML 
schema, not that the document is a valid XML document. The client 
application may receive a document that conforms to the XML schema but 
that is not a proper XML document. If the end condition has not been met, 
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another attempt can be made to transform the metadata into an XML 
document 404. If the end condition has been met, such as a number of 
iterations or timeout period end being reached, an error can be returned to 
the client application and processing of this request can stop 418. 



An XML schema is like a contract between the EIS and ah 
application on the other side of the adapter. This contract can specify how 
data coming from the EIS must appear in order for the application to 
manipulate it. A document, or an XML-rendered collection of metadata 
from an EIS, can be considered valid if it meets the rules specified in the 
schema, regardless of whether or not the XML is correct. For example, if 
a schema required a name to appear in a <name> element and that 
element required two child elements, such as <firstname> and <lastname>, 
to be valid, the document from the EIS would have to appear in a form 
such as: 

<name> 

<firstname>Joe</flrstname> 

<lastname>Smith</lastname> 
</name> 



and the schema would have to appear in a form such as: 

<schema> 
<element name="name M > 
<complexType> 
<sequence> 
<efement name="firstname" /> 
<element name^lastname* /> 
</sequence> 
</complexType> 
</element> 
</schema> 



No other form of <name></name>, such as "<name>Joe Smith</name> M 
would be valid, even though the XML is correct. 
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CreatinQ the Schema 

An XML schema can be created programmatically by using the 
classes and methods provided with SOM. One benefit of using such a tool 
is that it allows a user to tailor a schema for that user's needs simply by 
populating the variables in the program components. For instance, the 
following code examples create a schema that validates a purchase order 
document: 



import com.bea.schema.*; 

import com.bea.schema.type.SOMType; 

public class PurchaseOrder 
{ 

public static void main(StringQ args) 
{ 

System.out.println(getSchema().toString()); 

} 



public static SOMSchema get$chema() 
{ 

SOMSchema po_schema = new SOMSchema (); 

po_schema.addDocumentationCPurchase order schema for 
Example.comAnCopyright 2000 Example, com An All rights 

reserved."); 

SOMEIement purchaseOrder = 
po_schema.addElement( n purchaseOrder w ); 



SOMEIement comment = po_schema.addElement( n comment°); 



SOMComplexType usAddress * 
po^schema.addComplexTyperUSAddress"); 

SOMSequence seq2 = usAddress.addSequence(); 
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// adding an object to a SOMSchema defaults to type="string H 

seq2.addElementfname M ); 

seq2.addElement( ,, street B ); 

seq2.addElementfcity M ); 

seq2.addElement("state"); 

seq2.addElementC2ip w , SOMType.DECIMAL); 

One benefit to such a tool is that it is only necessary to populate the 
variables in the program components to tailor a schema for particular 
needs. Attributes can be set in the same way that elements are created, 
such as: 



SOMAttribute country_attr * 

usAddress.add Attribute ("country", 
SOMType.NMTOKEN); 
country_attr.setUse("fixed"); 
country_attr.setValueCUS M ); 

To correctly set these attributes, their addressibility should be 
maintained. Like complexTypes, simpleTypes can be added to the root of 
the schema, such as: 



SOMSImpleType skuType = po_schema.addSimpleType("SKU n ); 
SOMRestriction skuRestrict = skuType.addRestriction 

(SOMType.STRING); 
skuRestrict.setPattem("\\d{3HA-Z]{2n; 

SOMComplexType poType = 
po^schema.addComplexfypeCPurchaseOrderType"); 

purchaseOrder,setType(poType); 

poType.addAttribute("orderOate", SOMType.DATE); 



The addSequence() method of a SOMComplexType object can 
return a SOMSequence reference, allowing a user to modify the element 
that was added to the element. In this way objects can be added to the 
schema, such as by implementing an addSequence() method to modify an 
element: 

* 

SOMSequence poType_seq = poType.addSequence{); 
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poType_seq.addEIement( n shipTo", usAddress); 
poType_seq.addElement( M billTo", usAddress); 

Attributes of an element within a schema can be set by calling setter 
methods of a SOMEIement object. For example,.an the implementation of 
setMinOccurs() and setMaxOccurs() can be given by: 

SOMEIement commentRef = new SOMEIement(comment); 
comrnentRef.setMJnOccurs(O); 

poType_seq.add(commentRef); 
SOMEIement poTypeJtems = poType_seq,addElementntems H ); . 

SOMComplexType itemType « po_schema.addComplexType("lterns n ); 
SOMSequence seq3 = itemType.addSequencef); 
SOMEIement item = new SOMEIementCitenrT); 

item.setMInOccurs(O); 

item.setMaxOccurs(-1 ); 

seq3.add(item); 
SOMComplexType t = new SOMComplexTypeO; 

item.setType(t); 
SOMSequence seq4 = t.addSequence(); 

seq4.addElement{ ,, productName"); 
SOMEIement quantity seq^addElementCquantity"); 
SOMSImpleType st = new SOMSImpleTypeQ; 

quantlty.setType(st); 
SOMRestrlction restrict = 
st.addRestrictlon(SOMType.POSITIVEINTEGER); 
restrict.setMaxExclusivepOO"); 

In this example, the items element for PurchaseOrderType was 
created before Items type. The reference can be created and the type set 
once the Items type object is available, such as by using: 
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poTypejtems.setType(itemType); 



An element can also be added to the schema. Adding an element 
can be done by implementing an addElementQ method of SOMSequence, 
5 or the add() method from a previously created SOMEIement; These 

methods can be shown by: 

seq^addElementrUSPrice", SOMType. DECIMAL); 

SOMEIement commentRef2 » new SOMEIement(comment); 
commentRef2.setMinOccurs(0); 
1 0 seq4.add(commentRef2); 

SOMEIement shlpDate = new SOMEIementC'shipDate", SOMType.DATE); 

shipDate.setMinOccurs(O); 

seq4 .add(shipDate); 
t.addAttributeCpartNum", skuType); 

15 return po_schema; 

> 

} 

When running the code shown in the previous examples, the 
20 following schema can be created: 



<?xml version= n 1.0"?> 

<!DOCTYPE schema (View Source for full doctype...)> 
<xsd:schema xmlns:xsd s "http://www. w3.org/2000/XMLSchema"> 
25 <xsd:annotation> 

<xsd:documentation>Purchase order schema for Example.com. 
Copyright 2000 Exampfe.com. AH rights 
reserved.</xsd:documentatlon> 

</xsd:annotatlon> 

30 <xsd:simpleType name="SKU°> 

<xsd:annotation> 
</xsd:annotation> 
<xsd:restrlctlon base=°xsd:strlng"> 
<xsd:pattem value="\d{3HA-Z){2} ,> /> 
35 </xsd:restriction> 

</xsd:slmpleType> 

<xsd:complexType name= w PurchaseOrderType"> 
<xsd:sequence> 
<xsd:element type="USAddress M name^shlpTo" /> 
40 <xsd:element type= w USAddress" name="billTo" /> 



27 



WO 03/034228 



PCT/US02/33090 

4 



<xsd:element ref="commenr minOccurs- '()" /> 
<xsd:element type="Uems" name="items" /> 
</xsd;sequence> 

<xsd:attribute name="orderDate" type="xsd:date" /> 
</xsd:complexType> 

<xsd:complexType names-Items'^ 
<xsd:sequence> 
<xsd:element maxOccurs="unbounded" name="item" 
mfnOccurs="0"> 
<xsd:complexType> 
<xsd:sequence> 
<xsd:element type="xsd:string M 

name="productName7> 
<xsd:element name="quantlty"> 
<xsd:simpleType> 
<xsd:restriction base= 
"xsd^ositivelnteger^ 
<xsd:maxExclusive value="l007> 
</xsd:restriction> 
</xsd;simpleType> 
</xsd:element> 

<xsd:element type="xsd:decimar name 3 

"USPrice" /> 
<xsd:element ref="commenr 

minOccurs^O" /> 
<xsd:element type="xsd:date w 

name="shipDate" minOccurs^O" /> 
</xsd:sequence> 

<xsd:attribute name^partNum" type="SKU" /> 
</xsd:complexType> 
</xsd:e!emant> 
</xsd:sequence> 
</xsd:complexType> 

<xsd:complexTyp© name="USAddress n > 

<xsd:sequence> 
<xsd:element type^xsdrstfing'* name="name" /> 
<xsd:element type="xsd:string" name^streef /> 
<xsd:element type= n xsd:string" name="city" t> 
<xsd:element type="xsd:string" name="state w /> 
<xsd:element types-xsdinumber" name="zip" /> 

</xsd:sequence> 

<xsd:attribute name-'country use^fixed" value-'US" 
type="xsd:NMTOKEN" /> 
</xsd:complexType> 

<xsd:element type="PurchaseOrderType" name="purchaseOrder" /> 
<xsd:element type= N xsd:string" name="commenr /> 
</xsd:schema> 
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Validating an XML Document 

Once the schema is created, it can be used to validate a document 
sent from an EIS. SOM can be used to validate XML DOM documents by 
using a SOMSchema method such as isValid(). SOMEIement can have a 
corresponding isValidQ method for validating an element instead of the 
DOM document. The isValid() method can determine if 'document* or 
'element' is valid, and if not, can compile a list of the errors. If the 
document is valid, isValid() can return 'true' and the list of errors can be 
empty. 

An isValid() method can be implemented in a number of different 
ways, including the following ways: 

public boolean isValid(org.w3c.dom. Document doc, 

java.util.List enrorList) 
public boolean isValid((Document doc. 

List errorList) 

In this example, "doc" refers to the document instance to be validated, and 
"errorList" refers to a list of errors found in the document and/or doc. 

The isValid{) method can return a boolean value of 'true' If the 
document is valid with respect to this schema. If the document is not valid 
with respect to the schema, isValid() can return 'false' and the errorList can 
be populated. The errorList is a java.util.List for reporting errors found in 
the document, doc. The error list is cleared before validating the document. 
Therefore, the list implementation used must support the clear() method. 
If isValid() returns false, the error list is populated with a list of errors found 
during the validation procedure. The items in the list are instances of the 
class com.bea.schema.SOMValidationException. If isVa!id() returns true, 
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errorUst is empty. The following shows an example of an isValidQ 
implementation: 

SOMSchema schema = 

IDocument doc = DocumentFactory.createDocument 

(new FileReader(f)); 
java.util.LinkedList errorList = new 

java.util.LtnkedUst(); 
boolean valid = schema. IsValidfdoc, errorList);... 
if (! valid){ 

System.out.printlnC'Document was invalid. 
Errors were:"); 

for (Iterator i = errorList iterator; LhasNext();) 

( 

System,out.println(((SOMValidationException) 
, LnextJ.toStringO); 

} 

The foregoing description of preferred embodiments of the present 
invention has been provided for the purposes of illustration and description. 
It is not intended to be exhaustive or to limit the invention to the precise 
forms disclosed. Many modifications and variations will be apparent to one 
of ordinary skill in the art. The embodiments were chosen and described 
in order to best explain the principles of the invention and its practical 
application, thereby enabling others skilled in the art to understand the 
invention for various embodiments and with various modifications that are 
suited to the particular use contemplated. It is intended that the scope of 
the invention be defined by the following claims and their equivalence. 
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What is claimed is: 

1. A method for passing communication between an enterprise 
system and a client application, comprising: 

transforming metadata received from an enterprise system into an 
XML document; 

validating at least a portion of the XML document against an XML 
schema for the client application; and 

passing the XML document to the client application. 

2. A method according to claim 1 , further comprising: 
building the XML schema using an XML schema API. 

3. A method according to claim 1 , further comprising: 

4 

building the XML schema using a schema object model. 

4. A method according to claim 3, wherein: 

building the XML schema further includes using classes and 
methods in the schema object model 

5. A method according to claim 2, wherein: 

building the XML schema includes populating variables in program 
components of the schema object model In order to tailor the XML schema 
for the client application. 

» 

6. A method according to claim 1 , further comprising: 
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creating a schema object model to validate an XML schema for the 
client application. 

7. A method according to claim 1 , wherein: 

compiling a list of errors containing elements of the XML document 
that are not valid. 

8. A method according to claim 1 , further comprising: 

translating information passing between the enterprise system and 
the client application using a resource adapter. 

9. A system for passing communication between an enterprise 
system and a client application, comprising: 

a resource adapter adapted to receive metadata from an enterprise 
system; and 

an XML schema component adapted to transform the metadata into 
an XML document and validate the XML document against an XML 
schema; 

wherein the resource adapter is further adapted to pass a validated 
XML document to the client application. 

10. A system according to claim 9, further comprising: 

a schema object model adapted to provide the ability to create the 
XML schema. 
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1 1 . A system according to claim 9, further comprising: 

an application view component adapted to provide an interface to 
the enterprise system for the client application. 

* 

12. A computer-readable medium, comprising: 

means for transforming metadata received from an enterprise 
system into an XML document; 

means for validating at least a portion of the XML document against 
an XML schema for the client application; and 

means for passing the XML document to the client application. 

13. A computer program product for execution by a server computer 
for formatting enterprise data for an application, comprising: 

* 

computer code for transforming metadata, received from an 
enterprise system into an XML document; 

computer code for validating at least a portion of the XML document 
against an XML schema for the client application; and 

computer code for passing the XML document to the client 
application. 

i 

14. A system for formatting enterprise data for an application, 
comprising: 

means for transforming metadata received from an enterprise 
system into an XML document; 

means for validating at least a portion of the XML document against 
an XML schema for the client application; and 
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means for passing the XML document to the client application. 



15. A computer system comprising: 
a processor; 

object code executed by said processor, said object code configured 

to: 

transform metadata received from an enterprise system into 
an XML document; 

validate at least a portion of the XML document against an 
XML schema for the client application; and 

pass the XML document to the client application. 

16. A computer data signal embodied in a transmission medium, 
comprising: 

a code segment including instructions to transform metadata 
received from an enterprise system into an XML document; 

a code segment including instructions to validate at least a portion 
of the XML document against an XML schema for the client application; 
and 

a code segment including instructions to pass the XML document 
to the client application. 

17. A method for passing communication between an enterprise 
system and a client application, comprising: 

transforming metadata received from an enterprise system into an 
XML document; 
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querying the XML document using a document interface component 
in order to extract at least a portion of the XML document; 

validating said at least a portion of the XML document against an 
XML schema for the client application; and 

passing the XML document to the client application. 

18. A method according to claim 17, further comprising: 
building the XML schema using an XML schema API. 

1 9. A method according to claim 1 7, further comprising: 
building the XML schema using a schema object model. 

20. A method according to claim 19, wherein: 

building the XML schema further includes using classes and 
methods in the schema object model. 

21. A method according to claim 18, wherein: 

building the XML schema includes populating variables in program 
components of the schema object model in order to tailor the XML schema 
for the client application. 

♦ 

22. A method according to claim 17, further comprising: 

creating a schema object model to validate an XML schema for the 
client application. 
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23. A method according to claim 17, wherein: 

compiling a list of errors containing elements of the XML document 
that are not valid. 

24. A method according to claim 17, further comprising: 

translating information passing between the enterprise system and 
the client application using a resource adapter. 

25. A method for passing communication between an enterprise 
system and a client application, comprising: 

transforming metadata received from an enterprise system into an 
XML document; 

querying a document interface component in order to validate at 
least a portion of the XML document against an XML schema; and 

passing the XML document to the client application. 

26. A system for passing communication between an enterprise 
system and a client application, comprising: 

a resource adapter adapted to receive metadata from an enterprise 
system in response to a request from a client application; 

a document interface component adapted to allow the querying of 
elements in an XML document; and 

■ 

an XML schema component adapted to transform the metadata into 
an XML document and validate elements the XML document against an 
XML schema, the XML schema component obtaining the elements through 
the document interface component; 
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wherein the resource adapter is further adapted to pass a validated 
XML document to the client application. 

27. A system according to claim 26, wherein: 

the document interface component is an XML document API. 

28. A system according to claim 26, wherein: 

the document interface component is adapted to work with DOM 
documents. 

29. A system according to claim 26, wherein: 

the document interface component provides an XPath interface to 
elements in an XML document. 

30. A system according to claim 26, wherein: 

the document interface component allows portions of an XML 
document to be queried and updated using XPath strings. 

31 . A system according to claim 26, wherein: 

the document interface component comprises a container including 
a DOM instance and an XPath interface. 

32. A system according to claim 26, wherein: 

the document interface component is a public interface that 
represents an XML document. 
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33. A system according Jo claim 26, wherein: 

the document interface component allows manipulation of elements 
in an XML document, the manipulation selected from the group consisting 
of retrieving, modifying, adding, and removing data elements. 

34. A system according to claim 26, further comprising: 

a schema object model adapted to provide the ability to create the 
XML schema. 

35. A system according to claim 26, further comprising: 

an application view component adapted to provide an interface to 
the enterprise system for the client application. 

36. A computer-readable medium, comprising: 

means for transforming metadata received from an enterprise 
system into an XML document; 

means for querying the XML document using a document interface 
component in order to extract at least a portion of the XML document; 

means for validating said at least a portion of the XML document 
against an XML schema for the client application; and 

means for passing the XML document to the client application. 

37. A computer program product for execution by a server computer 
for formatting enterprise data for an application, comprising: 
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computer code for transforming metadata received from an 
enterprise system into an XML document; 

computer code for querying the XML document using a document 
interface component in order to extract at least a portion of the XML 
document; 

computer code for validating said at least a portion of the XML 
document against an XML schema for the client application; and 

computer code for passing the XML document to the client 
application. 

38. A system for formatting enterprise data for an application, 
comprising: 

means for transforming metadata received from an enterprise 
system into an XML document; 

means for querying the XML document using a document interface 
component in order to extract at least a portion of the XML document; 

means for validating said at least a portion of the XML document 
against an XML schema for the client application; and 

means for passing the XML document to the client application. 

39. A computer system comprising: 

a processor; object code executed by said processor, said object 
code configured to: 

transform metadata received from an enterprise system into 
an XML document; 
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query the XML document using a document interface 
component in order to extract at least a portion of the XML 
document; 

validate said at least a portion of the XML document against 
an XML schema for the client application; and 

pass the XML document to the client application. 

40. A computer data signal embodied in a transmission medium, 
comprising: 

a code segment including instructions to transform metadata 
received from an enterprise system into an XML document; 

a code segment including instructions to query the XML document 
using a document interface component in order to extract at least a portion 
of the XML document; 

a code segment including instructions to validate said at least a 
portion of the XML document against an XML schema for the client 
application; and 

a code segment including instructions to pass the XML document 
to the client application. 



-40- 



WO 03/034228 



PCT/US02/33090 



New 
Customer. 
Notification 



Publish 
Event 



Client Application 




100 



Update 
Customer 
Address 



Get 
Customer 
Detail 



Describe 
Method 



Process Service 
Request/Response 



(XML) 



Provide Meta 
Data 



Application View 



102 



SQL 



Database 
trigger 



Adapter 



Message 



Adapter 
H 108 



SQL 



Result 



Msg 
Queue 



Adapt^r l() 



SQL 



Result 



SQL 



Result 



Enterprise Information System 



104 



Figure 1 



1/4 



WO 03/034228 



PCT/US02/33090 




2/4 



WO 03/034228 



PCT/US02/33090 



Create an XML schema for a client application using a 

schema object model 

300 



i 



Receive metadata from an enterprise system In 
response to a request from a client application 



302 



Transform the metadata into an XML document 
appropriate for the client application 



304 



I 



Validate that at least a portion of the XML document 
conforms to the XML schema for the client application 

306 



I 



Pass the validated XML document to the 
client application as a response document 



308 



Figure 3 



3/4 



WO 03/034228 



PCT/US02/33090 



Receive request to an enterprise 
system (EIS) from a client application 

400 



i 



Return metadata from the EIS in 
response to the request 



402 



i 



Transform metadata into an XML 
document 

4M 



Compare at least portions of the XML 
document to an XML schema for the 
client application 



Return error to client 
application 

m 




Is each portion 

valid? 

408 



No 



Should client 
receive invalid 

document? 

412 



Yes 



Pass validated XML document to client 
as a response document 



Yes 



Log error 



414 



Figure 4 



4/4 



INTERNATIONAL SEARCH REPORT 



International application No. 
PCT7US02/33090 



A. CLASSIFICATION OF SUBJECT MATTER 

IPQ7) : G06F 12/00. 17/30 

USCL : 707/513 
According to International Patent Classification (IPC) or to both national classification and IPC 



B. FIELDS SEARCHED 



Minimum documentation searched (classification system followed by classification symbols) 
U.S. : 707/513 



Documentation searched other than minimum documentation to the extent that such documents are included In the fields searched 
IEEE 



Electronic data base consulted during the international search (name of data base and, where practicable, search terms used) 
Please Sec Continuation Sheet 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category * 



Citation of document, with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



US 6,226,675 Bl (MELTZER et al) 01 May 2001 (01.05.2001). column 3. lines 2&-*\. 
column 7. lines 55-61. column 22. lines 39-51, column 23, lines 43-46, column 25, lines 
28-51, column 26, lines 1-9, column 30. lines 43-45. column 79. lines 47-52. 

US 6.154.738 A (CALL) 28 November 2000 (28.1 1.2000). column 24, lines 45-59, column 
25, lines 26-34, column 32, lines 20-25. 



1-40 



1-40 



□ 



Further documents are listed in the continuation of Box C. 



□ 



See patent family annex. 



* Special ciiegortes of cited documents *T' 

'A* docnmeo* defining the general state of the art which is not coosWeitd to be 
of particular relevance 

-x* 

*E~ earlier application or patent published oo or after the toieroatiooal filing date 

"L" document which may throw doubu on priority ctaimft) or whfcb is cited to 

establish the publication date of another elation or other special reason (as *Y* 
specified) 

*0* document referring to in oral disclosure, use, exhibition or other means 

*P* document published prior to (he international filing date but Istcr than the "A" 
prtoriry date claimed 



later document published after the international filing date or priority 
date and not la total to with the application bat cited to understand the 
principle or theory underlying the invention 

document of particular relevance; the claimed invention cannot be 
considered novel or cannot be considered to Involve an inventive step 
when the document b taken alone 

document of particular relevance; the claimed invention cannot be 
considered to involve an Inventive step when the document b 
combined with one or more other such documents, such combination 
being obvious lo a person skilled 1st On an 

document member of the same patent family 



Date of the actual completion of the international search 
13 January 2003 (13.01.2003) 



Name and mailing address of the ISA/US 

. Cornrnisskmrr of Patents and Trademarks 
Boa PCT 

WaAmgton. DC 20131 

Facsimile No. (703)305-3230 



Date of mailing of the international search report 

TR 2003 



Authorized officer 
Heather Hemdon 
Telephone No. (703)305-4700 




Form PCT/1SA/210 (second sheet) (July 1998) 



! 



INTERNATIONAL SEARCH REPORT 



PCT/USO2/3309O 



Continuation of B. FIELDS SEARCHED Item 3: 
EAST 

search terms: XML, DOM, object model, transformation, translation, conversion, converting, schema, validation, metadata 



» 



Form PCT/ISAy210 (second sheet) (July 1998) 



